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REMARKS 

Claims 1-18 are pending. In the Office Action mailed on July 26, 2005, the 
Examiner rejected claims 1-18 under 35 U.S.C. § 103(a) over U.S. Patent No. 6,006,215 to 
Retallick ("Retallick"). Further examination and review in view of the remarks below are 
respectfully requested. 

Applicants' techniques are directed to providing collaboration among workers. In 
some cases, the collaboration occurs through the sharing of smaller tasks among the 
workers, also referred to as resources, involved in a larger project. Responsibility for 
tasks, also referred as task ownership, can be delegated from a project manager to the 
resources working on the project. Moreover, any resource may delegate a task to any 
other resource. As a project progresses, tasks can be transferred from one manager to 
another manager and/or resource, with the transferring manager retaining varying levels of 
control over the delegation process, for example, from a strictly controlled approach to a 
flexible, highly collaborative approach. In operation, when a resource (delegator) 
delegates a task to another resource (delegatee), the delegator's client sends a delegation 
message to a server. In response to receiving the delegation message, the server 
forwards the new task ownership information to a database and also communicates the 
delegation information to the delegatee's client and the project manager client. 

All of the claims stand rejected over Retallick. Retallick merely describes using a 
database to create, store and retrieve linked records to facilitate contact and activity 
management, (col. 1, line 66-col. 2, line 4). According to Retallick, users utilize screens to 
enter data into named fields to create Activity, Contact and Topic records, which are stored 
in the database for later retrieval, (described at col. 2, line 41 -col. 3, line 16, and shown in 
Figs. 5-10). The records in the database: are to be recalled and reviewed by the users 
(col. 3, lines 26-28); can be retrieved for review by the users (col. 4, line 60); are 
retrievable by a user (col. 6, lines 29-30); and can be recalled and displayed by users (col. 
7, line 35). In Retallick, when a task is delegated to a user, an Activity record is created 
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and added to the user's ToDo List, allowing the user to view the list of the activities, (col. 
4, lines 53-59; col. 6, lines 61-64). Thus, according to Retallick, the delegation is recorded 
by the creation and the addition of the Activity record to the user's ToDo List, and the user 
becomes aware of the delegation when the user calls up his/her ToDo List and displays 
the Activities in the list. (col. 9, lines 14-30). 

All of the claims each recite sending task delegation information from the server to a 
resource client and to a project manager client, wherein the delegation information is 
distinct from the record of the task delegation sent from the server to the storage 
medium, or similar language. In rejecting the claims, the Examiner indicated that 
Retallick's means for exchanging a commitment dialog (col. 6, line 61 -col. 7, line 10 and 
. 23-28) corresponds to Applicants' task delegation information that is distinct from the 
record of the task delegation sent from the server to the storage medium. In particular, 
the Examiner stated: 

After carefully re-considering the prior art of record, the examiner found that 
Retallick's system requires pre-acceptance from a target recipient when 
delegating a task. In the process, the server (i.e., the delegation module) 
provides a means of exchanging commitment dialog [see col. 6, line 61 -col. 7, 
line 1-10 and 23-28]. Thus, it is clear that the dialog between the sender and 
recipient is different from the data being sent to the database. 

Applicants respectfully disagree. According to Retallick, the embodiment of the 
invention that includes a Task Delegation Module is capable of assessing a User's daily 
workload and providing assistance in the management of that workload, and providing a 
means of exchanging commitment dialog so that all Users can act in a common 
environment of committed actions, (col. 7, lines 23-28). The only possible disclosure of 
a commitment dialog in Retallick is made at col. 6, line 61 to col. 7, line 22, which states: 

The present invention can include a module for task delegation (Task Delegation 
module) (sending an Activity to a Recipient) that permits the Sender-Recipient 
link to be bidirectional. That is, when an Activity is created that establishes an 
Action (or other Activity Type) that requires some task to be performed or 
response to be made by a Recipient, that task or response is not added to that 
Recipient's ToDo List without limitation, restriction or pre-acceptance. Instead of 
the Recipient having to manually reject a task by creating another Activity to 
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either send the task back to the Sender or to another Recipient (which the 
Recipient always has the option to do), the Sender will be alerted that the 
Recipient is unavailable (such as on vacation, or on a business trip, or not 
accepting new tasks, etc.). When that occurs, the Sender will have to modify the 
Activity in order to have it entered (a non-rejecting Recipient is a prerequisite to 
entering an Activity). The Task Delegation module creates a high level of 
sophistication by providing means by which the status of every User's workload is 
recorded as a Daily Activity Profile and available to be taken into account in 
allocating tasks. Once a database of daily Activity Profiles is created, the 
invention is able to monitor each User's daily workload for available time. Using 
this information, the invention will permit, permit with warning, reject with warning 
or reject outright, an Activity sent by a User (Sender) to Recipients, depending on 
limits established relative to the Daily Activity Profiles. Each User is able to 
adjust his/her Daily Activity Profile as a way of regulating his/her workload. 

According to Retallick, the commitment dialog is between the Task Delegation 
Module and the user's Daily Activity Profile. In particular, the Task Delegation Module 
takes into account the user's workload as recorded in the user's Daily Activity Profile in 
allocating tasks to the user. Using the information in the user's Daily Activity Profile, the 
Task Delegation Module permits, permits with warning, rejects with warning, or outright 
rejects, an Activity sent by a Sender to Recipients. Subsequent to checking the 
Recipient's Daily Activity Profile (i.e., performing the commitment dialog), the Task 
Delegation Module delegates an Activity by adding it to the Recipient's ToDo List. 

In the present Office Action, the Examiner asserted that "it is clear that the dialog 
between the sender and the recipient is different than the data being sent to the 
database." Applicants respectfully disagree. First, as explained above, the commitment 
dialog, which arguably may be different than the record of the task delegation sent from 
the server to the storage medium, is between the Task Delegation Module and the 
appropriate Daily Activity Profile (i.e., the Task Delegation Module checking the Daily 
Activity Profile). Second, Retallick teaches that the Recipient can manually reject a task 
by creating another Activity to either send the task back to the Sender or to another 
Recipient, (col. 7, lines 2-5.) As explained above, an Activity is sent to a Recipient by 
adding it to the Recipient's ToDo List, and the Recipient calls up his/her ToDo list to 
display the Activities scheduled for him/her for that day. (col. 9, lines 26-29.) When an 
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Activity record is created, the activity is automatically added to the Recipient's ToDo List, 
(col. 4, lines 53-55.) In Retallick, the communication of the assignment of an Activity is (1) 
from the server (i.e., the Task Delegation Module) to the storage media and (2) from the 
storage media to the client, in that the Task Delegation Module creates an Activity record 
in the storage media, which automatically causes the Activity to be included in the 
Recipient's ToDo List, again in the storage media, for subsequent retrieval and viewing by 
the Recipient. Therefore, in contrast to the Examiner's assertion, in Retallick, there is no 
direct communication of the assignment between the server (i.e., the Task Delegation 
Module) and the client (i.e., Recipient of the assigned Activity). At best, any indirect 

. communication of the assigned Activity from the server to the client in Retallick is via the 
Activity record that is created in the storage media. This is in contrast to Applicants' server 

' that sends the task delegation information to a delegated client and a project manager, 
where the task delegation information is distinct from the record of the task delegation 
sent to the storage medium . Applicants can find in Retallick no such disclosure or 
suggestion. 
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Conclusion 



In view of the foregoing, Applicants respectfully submit that claims 1-18 are 
allowable and ask that this application be passed to allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-8000. 




Dated: fa 0 *~ Respectfully submitted, 





Do Te Kim 

Registration No.: 46,231 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 981 1 1 -1 247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicant 



12 



